26 April 2022:
================================================================================
Started with the last working BASIC-only version from the VIC (IL11) and removed all the colour control codes, replacing the "Illuminati" references in the instructions with reverse on/off. Nothing else has changed. This won't look right, at all, but it passes the time while waiting to find out what's gone on with the machine code version (IL17) on the VIC. A throwaway line has been added at the beginning - let's see if it works... this is really just to test if it'll load properly. [PET01]
Loaded... but didn't list or run (just blank).
Tried the technique in Appendix Q of "Programming the VIC":
POKE 4096,0: POKE 41,16: CLR
Loaded... but only from line 2115 onwards.
Loaded IL11 into the VIC and then saved it to tape from the VIC. [PET01A]
Tried the same trick and this one didn't show up at all...
PEEK(830)=0, so POKE 4096,0: POKE 41,0: CLR
(PEEK 4096=170 and PEEK 41=4 on startup on a PET 3016.)
Well, that didn't work... LIST produced nothing.
Try the bottom of page 595. Loaded IL11 into the VIC, PEEK(830)=0.
Saved a copy [PET01B] at the end of the tape.

27 April 2022:
================================================================================
Saving to tape on the C64 and reloading on the PET still loads the wrong number of bytes into the computer. PET01 is 7270 bytes but 8294 will be used on the PET - exactly 1024 bytes more than is necessary...? That's a clue that something is off and it's not necessarily the tape speed. (C64 is the same speed, more or less, as the PET.)
POKE 33767 to put a character in the bottom right corner.

Switching to CBM PRG Studio. Let's see what this can produce!

Changed all the VIC bottom-right squares to POKE 33767,160 (some will need to be 32), removed the POKEs for the VIC screen memory, and all the control codes in the text.
Temporarily amputated the instructions because that might be too much to handle.
Reworked the Illuminati logo and front page so it resembles the ZX81 version again.
This is 5452 bytes by the internal length calculator. [PET02]

Reworked the pyramid so that it prints in the right place...
[PET03A] (with the pyramid top split from the eye) is 5826 bytes.
DON'T CHANGE REM STATEMENTS! [PET03E] has the pyramid reworked so that it prints the 15 cells via a loop. This is 5600 bytes. Excellent.
(Can also improve the VIC program this way...)

7 May 2022:
================================================================================
Most of the above was junked - the VIC version was so vastly improved that all the other PET starts above are completely outdated. Retained the Illuminati logo, though.
Made a test of holding the machine code in a REM statement (SYS1031 to execute the code) - but it does weird things. If CBM prg Studio contains {4}, the resultant code in the program will be... 52.
Occurs at 1035,1047,1054,1063,1075,1081,1090,1097,1114.
1 is OK at 1109. 3 is OK at 1129.
7 has become 55 at 1132 and 1143.
It's not a problem with the displaying CHR$(4) in the listing so some pokes can be applied. And then in the final version this line can be removed after running the program.
Putting {04} in the listing rather than just {4} solves the problem. Did it for all single digits, not just 4 and 7.
Transferred IL30 to CBM prg Studio.
Replaced the machine code REM statements with this PET version.
Took out all the colour references including POKE SC. Corrected SP to 
Changed all the capitals in the text to lower case. (Taken from PET04.)
Converted control codes to CPS format, and all the "{cm i}" to "{162}", for example - to ensure consistency between PET and C64.
It loads into the PET 2001, but only 717 bytes left before anything has been run! And obviously it will be full of errors. [PET05]

Correcting errors... initially cut out instructions and put them in a separate file. [PETINSTR]

Debugged the positioning of all the text, or at least that's the intention. [PET06]
For some unfathomable reason, line 2250 would not work. This uses LEFT$ to chop up Y$ ("down" control characters) and X$ ("right" control characters) according to the values of C%(M,3&4) which hold the correct screen positions for all the hex codes in the pyramid. PRINTing these shortened Y$ and X$ works in every other instance, except this one! It prints the inverse characters instead of the control codes they represent. Weird.
Does Commodore BASIC 1.0 (this is 1.0, right?) not accept arrays or %s as legitimate variables in LEFT$ and the rest? I tried defining the whole string as a dummy variable, and using MID$ instead of LEFT$, the result was always the same. Resorted to using POKE instead. Technically, then, we don't need H$ until the final comparison with the Evil Eye but I'll keep it in there for the C64 version and put line 2250 back as it should be.
What is happening (or not)? I know the addresses have been calculated properly but only blank space is being POKEd onto the screen. WTF?
Still, *some* of this can be sorted out by direct POKEs to the screen (such as the much-simplified score fuse, which is an advantage).


14 May 2022:
================================================================================
As per the latest VIC-20 version, changed all the LEFT$(X$,n) to SPC(n) to see if that cured the problem with printing the characters on screen. [PET07]
It didn't...

Maybe change the definition of Y$ to use CHR$ instead of printed "down" characters...?


15 May 2022:
================================================================================
Well... using {17} in the listing instead of {down} (for instance) made no difference. [PET07A]
Neither did building up Y$ from nothing by adding CHR$(17)... [PET07B]
Tried the same but put line 2250 back to "standard"... (i.e. lines 2240-2246 REMed out again and 2250 restored) - it's throwing inverse characters all over the screen. Gah! [PET07C]
The remaining problem with PET07A/B is still in the score fuse. Might have to change this to all pokes as well.


21 May 2022:
================================================================================
Changed the score fuse to direct pokes to the screen, and changed the bits that need to be reverted for the C64 version to comments in the text. [PET08]
I notice that the problems with PRINT only start after the machine code is executed, and every time I change one POKE, the next PRINT line corrupts into a series of inverse characters as well. So there is something about the machine code that is causing this.


22 May 2022:
================================================================================
itsP may have solved the problem:
https://www.commodore.ca/manuals/pdfs/commodore_pet_memory_map.pdf
Seems the addresses E0h-F8h on the zero page are used by the 40-column screen, which we have - but F9h-FFh are free. Using PET08 as a basis, change the machine code and see what happens... [PET09]
...that's broken it even further! The codes in the pyramid now come up as inverse question marks!
May have to not use the zero page and set a bit of memory above RAMTOP for it.
PET 2001-8N produces 0 when "Start of BASIC" addresses are PEEKed (40 and 41) and "End of BASIC" as well (52 and 53). PET 3008 returns 1 & 4 for PEEK 40 & 41 (as expected), 0 & 32 for PEEK 52 & 53 (as expected, top of BASIC is 8192).
So... is a PET 2001-8N BASIC 1.0? Is this the source of our zero page problems?

As I thought, it is. I've loaded PET07 into a 3008 and it isn't doing the same weird thing with the screen. It would make sense to debug the program on a 3008 and then rehash it (which is probably just going to be the machine code) on a 2001.

[PET3A] is the first version based on PET08 with the POKEs reverted to PRINTs just to see what happens.
Something's wrong with the "You brainlet..." and "Not this time..." captions, and also the machine code isn't working correctly.
Fixed the "brainlet" caption but (despite checking that only 39 characters are printed) the "Not this time" caption is still broken along with the Illuminati code. Maybe there's still trouble with the zero page. [PET3B]

Tried the zero-page-shifted code from PET10. This has fixed the problem with the "Not this time..." caption but the hex codes in the pyramid now show up as a pi character followed by a space. So we're still doing things wrong with the zero page, even in BASIC 2.0. [PET3C]
STILL FORGOT TO CHANGE THE PEEKS!

There's only one thing for it... go back to the full-address codes. We can (probably) use REM statements provided that MEM2 is non-zero before we RTS (so that there's no problem with listing the program afterwards).
had to split the main code into two and JMP over the line number and the REM. Noticed the PEEK problem when the results were still appearing as pi characters, but this is now fixed. POKE 1185+(1 TO 4) for the inputs, and PEEK(1190) and PEEK (1191) for the outputs in this version. [PET3D]
Cracked it! (On the PET 3008, at least!)

BUT will fixes to PET3C work? No, they didn't (BC/AD comes out as D3 when it should be E3). Tried it on the 2001 as well and the control character madness appears on the screen again. Just to be certain...!

Will PET3D work on the 2001? IT DOES! Just need to debug the end sequence now because it's still set to VIC-20 screen positions. 
Also got rid of a problem with the "random" number generator coming up with C9 for the target every time... need to use RND(1) instad of RND(0) from the VIC-20 version. It's still not particularly random, though. Looks like adding a dummy variable =RND(-TI) will do the trick. (The VIC-20 manual said to do so, hence this was a fine opportunity to tweak the VIC-20 version as well.) 1,812 bytes remain after a successful game. Can we re-add the instructions? [PET3E]

Made a few optimisations where possible. Now 1,903 bytes remaining after a successful game. [PET3F]

Put the instructions back (and corrected the positioning and further than PETINSTR). Now a mere 341 bytes remaining after a successful game, but it still works! [PET3G]
This can be official version 1.0 - it saves OK to disc, but the 2001 is giving problems with the tape. However, the tape will load into a 3008.
I still don't know why this is...


